WIP: Add an Application Model object #148
Conversation
|
This feature was requested by Office of CTO. I would like to vet the idea among ourselves, then when we think it is looking good ask for their input as well (before merging). |
| The Hydra approach identifies four important roles: | ||
|
|
||
| - The developer: Creates and maintains components (microservices) | ||
| - The application architect: Defines an application as composed of components |
There was a problem hiding this comment.
The architect role makes sense, though we already have roles-and-responsibilities section, we may want to consider aligning them together?
There was a problem hiding this comment.
Yeah, I will fit the ideas in this document into the other sections.
There was a problem hiding this comment.
Some of the customer feedback I received last week was that developers shouldn't be concerned with component creation or maintenance. In the customers' opinion, workload type and resource consumption should be an application architect concern, and developer involvement should drop off @ CI/CD.
I'm not saying we necessarily have to nix the developer from the personas, but it's something to consider in the future.
There was a problem hiding this comment.
Good point, and this is why components can be specified inline (by app architects) for those orgs. But I got other feedback saying the app developers ought to be able to have complete control over their component configurations, so they needed the option to have separate files.
To solve this conundrum, I made it so that the components section could either define the components inline (e.g. the "strong app architect" model) or provide a reference to component specs created by developers (the "strong developer" model).
|
This proposal looks great and promising. |
4.application_model.md
Outdated
|
|
||
| ## Representation | ||
|
|
||
| The `ApplicationModel` object follows the same basic structure as all Hydra manifests. |
There was a problem hiding this comment.
Just follows the structure as below
4.application_model.md
Outdated
|
|
||
| ### Metadata | ||
|
|
||
| Metadata describes this trait. The metadata section is defined in [Section 3](3.component_model.md#metadata). |
There was a problem hiding this comment.
Metadata describes basic information of this object.
There was a problem hiding this comment.
I'll fix this.
4.application_model.md
Outdated
|
|
||
| ### Metadata | ||
|
|
||
| Metadata describes this trait. The metadata section is defined in [Section 3](3.component_model.md#metadata). |
There was a problem hiding this comment.
There are a few references to trait here. Is that copy/paste artifact? I'm guessing yes....but if not, there should be something here that links to traits and clarifies the relationship.
There was a problem hiding this comment.
Oops... copy/paste mistake. Good catch.
Signed-off-by: Matt Butcher <[email protected]>
technosophos
force-pushed
the
feat/application-model
branch
from
aece3d1
to
3847b6e
Compare
| - name: path | ||
| value: "/" | ||
| # For these, we are just declaring the instance names, not setting params or | ||
| # traits. |
There was a problem hiding this comment.
Why? Aren't parameters and traits required to instantiate the database and admin-portal components, both of which are necessary in order for the application to run successfully since they're part of the same application model as the front-end component?
|
THIS PR IS ON HOLD. I don't think this is the correct solution to the problem. But there is still ongoing discussion, so I will leave this open for now. |
This adds an Application Model top-level object.
This is currently a WIP, and is not complete. However, comments at this early phase are welcome.
Signed-off-by: Matt Butcher [email protected]